I can not find such information anywhere.
I got one info that it is available from Win32s, but it is unclear if it is valid.
What is source of this information?

I don't have any sources, however it requires the NMHDR structure which is guarded by the same WINVER check, which causes a build failure when WINVER is set lower.

I think you use Windows headers incorrectly.
Default OW _WINVER is defined as 0x0400 that it can not be a problem.
It looks like you setup _WINVER to something lower then 0x0400.
But prsht.h header file is available in Windows SDK for _WINVER 0x0400 and above that use it for older Windows version is incorrect.
It is reason why anything in prsht.h is not guarded against _WINVER 0x0400, it is non sense.

The problem is that prsht.h is included indirectly by other Windows headers, including commdlg.h (needed for GetOpenFileNameA, which exists in Win32s), as well as by winspool.h. Both of these headers are included by windows.h when WIN32_LEAN_AND_MEAN is not defined.

It looks like Win32s doesn't include or reference prsht.h any way.
I will check NT 3.1 SDK for it.

NT3.1 SDK also doesn't contain prsht.h header file.
It looks like only NT 4.0 and above has prsht.h header file and it works correctly.
Any lower Windows version 4.0 cannot be used with prsht.h.
It looks like implementation of Windows header files is for Windows NT 4.0 and above only.

The error for Win32s with WINVER=0x030A is:

/usr/src/open-watcom-v2-upstream/rel/h/nt/prsht.h(648): Error! E1022: Missing or misspelled data type near 'NMHDR'

winuser.h in the NT headers does not define NMHDR unless WINVER >= 0x400.

So if NMHDR is not valid for Windows 3.1, and the property sheet stuff didn't exist in Windows 3.1, why should prsht.h declare anything at all? Or better yet, why is it included anyway?

My comment note that it is not simple problem as it looks like. This PR (partial change) only mask a problem because existing OW WIN32 header files are supporting Windows NT 4.0 and above. To really solve this issue need to review header files (add appropriate guards for lower versions) to be compatible with Win32s, Windows NT 3.1 and Windows NT 3.5 that it is much more work. Now it is failing that user understand that some problem exists otherwise user will require full support for Win32s, Windows NT 3.1 and 3.5 etc. If anybody do such review I will accept it but this change is unwanted because mask problem only. It will require add new linker target too.